As is well known, software quality assurance (QA) is a very important part in the whole software development lifecycle due to its contribution to ensure software quality before the software being delivered to end users. However, most of its work has to be performed in a very primitive way. Many QA engineers have to click or input on the GUI widgets (even text-based interfaces) of the AUT (Application under test) manually and repeatedly. Especially in a globalization test environment, the workload of the QA engineers will be multiplied with the increase of the number of target languages of the AUT. This is the reason why there is such a great demand for the development of test automation technology.
However, so far, it is difficult to realize GUI test automation in a globalization environment with existing test automation technologies. Globalization is an important trend in the current software industry, since almost all software vendors are trying to extend their products to the worldwide market. In such a case, their products will be localized into different languages to meet the preferences of customer who may have different native languages. This poses a challenge to QA engineers. They have to verify functions of the software across multiple languages to ensure it can work in other language versions as in its base language version (e.g. English). With existing test automation technologies, QA engineers can develop test assets as expected on one language platform, e.g. English, but they will find those test scripts can not work on a platform based on another language. As a result, they have to execute the test scripts automatically on the base language platform, but test manually or re-create test scripts on other language platforms, although the different language versions of the AUT have the same functions and GUI widget layouts except only difference in their presentations caused by different language localizations. That is, test scripts created in a base language environment cannot be reused in other language environments, thus causing a lot of redundant efforts for creating and executing test scripts in multiple language environments respectively, as well as the waste of time, resource and cost.
Essentially, the real cause underlying this problem is the limitation of traditional GUI test automation technologies in GUI widget identification.
On one hand, in GUI test automation technologies, the common workflow is first to create test assets such as test scripts (in Java, or other languages) by recording or development, and then to playback them in the end environment. Of these two phases, the first phase is more important, with its main task being to collect and store information on which GUI widgets are to be tested and their related logics, which GUI widgets and logics will necessarily be played back, in order to “tell” a runtime engine which and when GUI widgets need to invoke what logics such as clicks, double-clicks, etc. However, it is not easy to collect and store information on which GUI widgets are to be tested and their related logics, especially due to GUI widget identification. This is because, whatever method is used, a set of stable identification properties must be defined and determined.
On the other hand, the properties taken to identify GUI widgets in existing technologies, such as IBM's Rational Functional Tester, HP Mercury' Quick Test Professional, etc., are language-sensitive, which makes test scripts unable to work in a globalization environment. FIGS. 1 and 2 show an example of such a case. In the English environment shown in FIG. 1, the GUI control “Button” is identified by the language-sensitive property, “&Finish”, while, in the Chinese environment shown in FIG. 2, the same GUI control is identified by the language-sensitive property, “(&F)”, which will cause the test scripts recorded and developed in the English environment cannot be reused in the Chinese environment, since a same GUI widget will be identified as different things in different language environments.
Therefore, there is need for a solution which can identify GUI widgets correctly, uniquely and stably across different language platforms by finding a language-independent identification property.